In this series of blog posts, we’ll be talking in detail about how to write product release notes. Here's the first post, if you haven't checked that one out.

So, assuming you have, let's say you're now happy with who it is you're writing for, and you're ready to write the best goddamn release note that anyone has ever seen.

Except... not just yet, please. There's one more important thing to consider before you put digital-pen to digital-paper: Timing. And Frequency.

So there are some basic rules in terms of when post anything on the internet for someone to read it. These rules generally apply for just about any piece of content alongside changelogs for SaaS or any other business.

Timing is Everything

Don't post content on the weekends, obviously. Even if you're a B2C company, you're better posting during the week when more people will be at a computer.

Also avoid Mondays (where people are too sad the weekend is over) and Fridays (where people are too distracted the weekend is about start) if you can. That leaves the middle of the week, where people tend to be the most 'on it' and likely to notice you.

As for exact times, it's not quite as important a thing to worry about as it might be for something with a time limit on viewing, like a Twitter post but it's worth thinking a little about and you can maximize a new post with global time zones.

For example, 1 pm GMT is a good time for us to post in the UK, as it's early enough in the day for our European audience, but the Eastern Seaboard is also already likely to be at their desks, too. Any earlier and the Americans are still asleep. Much later, and the Europeans will start to clock off.

You can mitigate this a little if you have changelog software like ChangeCrab, as you'll always get that little update dot appearing on your site. Try not to post at 5 AM if you can help it, but if you do, take solace in the fact that it's always lunchtime somewhere in the world.

Frequency is also everything

There's a couple of schools of thought when it comes to release note frequency. The good or bad news, depending on your attitude, is there isn't one completely right answer when it comes to software changelogs.

Firstly, posting smaller updates often. This is, generally, our recommendation. The biggest reason is that shorter posts simply end up being less intimidating and more readable, but there are other advantages too. It gives each change a little more weight and it makes your business look more active and responsive in general. It also puts you and your team into that update-and-inform frame of mind.

Secondly, posting bigger release notes, less often. Did you see that one coming? The advantage of this method is that it can look really great to make that big exciting update with all the new features in one place. If your features all about improving a particular area of your site, it's easier to tell a story.

It's also likely you've simply been trained to do big, single posts from writing blogs in the past. Blogs are so over man. Except for this one, obviously.

There's no wrong answer, here. We don't recommend making a new changelog for every single bug fix you make, but we also don't recommend saving everything up into one 2,000 words long monthly update essay.

Only a sith deals in absolutes though, so one method we often use is to do a little bit of both. We'll do smaller updates that highlight individual features, but also a larger changelog if a set of work in a particular week works well together as a post.

Changelogs as a Service

It's a lot easier to post more frequent updates if the updating tool you use doesn't start with "W" and end in "ordpress", not pointing any fingers.

Our release notes tool, ChangeCrab, lets you set up a changelog for our business in minutes and, even more importantly, takes out the feeling of boiling a swimming pool to heat an egg that you feel every time you load up a big CMS to do a quick update.

Check us out!